home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Danny Amor's Online Library
/
Danny Amor's Online Library - Volume 1.iso
/
html
/
rfc
/
rfcxxx
/
rfc767
< prev
next >
Wrap
Text File
|
1995-07-25
|
60KB
|
2,380 lines
RFC:767
A STRUCTURED FORMAT FOR TRANSMISSION OF MULTI-MEDIA DOCUMENTS
Jonathan B. Postel
August 1980
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291
(213) 822-1511
< INC-PROJECT, MMMSFS.NLS.21, >, 5-Sep-80 20:19 JBP ;;;;
Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
TABLE OF CONTENTS
PREFACE ........................................................ iii
1. INTRODUCTION ..................................................... 1
1.1. Motivation ................................................... 1
1.2. Scope ........................................................ 1
1.3. Terminology .................................................. 1
1.4. Document Description ......................................... 2
1.5. Other Work ................................................... 2
2. SPECIFICATION .................................................... 3
2.1. Document ..................................................... 3
2.2. Message Objects ............................................. 5
2.3. Body Structures ............................................. 13
2.3.1. Simple Elements ........................................... 13
2.3.2. Structured Text ........................................... 13
2.3.3. NLS File Example .......................................... 13
2.3.4. Multimedia Structures ..................................... 15
2.3.5. The Media ................................................. 21
2.3.6. TEXT ...................................................... 22
2.3.7. VOICE ..................................................... 22
2.3.8. FACSIMILE ................................................. 23
2.3.9. GRAPHICS .................................................. 24
3. EXAMPLES & SCENARIOS ............................................ 25
Example 1: Text Example .......................................... 25
Example 2: Multimedia Example .................................... 28
REFERENCES .......................................................... 31
Postel [Page i]
August 1980
A Structured Format for Transmission of Multi-Media Documents
[Page ii] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
PREFACE
This is the first edition of this format specification and should be
treated as a request for comments, advice, and suggestions. A great
deal of prior work has been done on computer aided message systems and
some of this is listed in the reference section. This specification was
shaped by many discussions with members of the ARPA research community,
and others interested in the development of computer aided message
systems. This document was prepared as part of the ARPA sponsored
Internetwork Concepts Research Project at ISI.
Jon Postel
Postel [Page iii]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Postel [Page iv]
RFC: 767 J. Postel
USC-ISI
August 1980
A STRUCTURED FORMAT FOR TRANSMISSION OF MULTI-MEDIA DOCUMENTS
1. INTRODUCTION
This document describes a format for transmitting structured data
representations of multimedia documents. This format is intended to be
used with the Internet Message Protocol in an internetwork message
delivery system. That system is designed to transmit messages between
processes in host computers called Message Processing Modules (MPMs).
MPMs are located in several networks and together constitute an
internetwork message delivery system. The Internet Message Protocol
defines a message as being composed of an Identification, a Command, and
a Document. This report is intended to define the format of such
Documents. The reader is assumed to be familiar with the Internet
Message Protocol [1].
1.1. Motivation
Computer applications are being implemented which interact with users
in a variety of media (text, graphics, facsimile, speech). As
computer devices become available to process multimedia information it
becomes desirable to use computers to exchange multimedia information
between programs and users via various mechanisms including computer
mail.
1.2. Scope
This format is intended to be used for the transmission of multimedia
documents in the internetwork message delivery system, but it is
thought that it has a wider applicability.
1.3. Terminology
The messages are routed by a process called the Message Processing
Module or MPM. Messages are created and consumed by User Interface
Programs (UIPs) in conjunction with users.
The basic unit transferred between MPMs is called a message. A
message is made up of a transaction identifier (which uniquely
identifies the message), a command (which contains the necessary
information for delivery), and document. The document is a data
structure.
For a personal letter the document body corresponds to the contents of
Postel [Page 1]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Introduction
the letter; the document header corresponds to the date line,
greeting, and signature.
For an inter-office memo the document body corresponds to the text;
the document header corresponds to the header of the memo.
The commands correspond to the information used by the Post Office or
the mail room to route the letter or memo. Some of the information in
the command is supplied by the UIP.
1.4. Document Description
The document is composed of fields. Each field will carry an
identifying name. Typical fields are DATE, TO, SUBJECT, and BODY.
Most of the fields will be very simple, some will be complex. The
body field may be quite complex. For example, the DATE is a very
constrained character string specifying the date and time in ISO
format. A more complex example is the TO field which is a list of
mailboxes, where a mailbox is itself a property list of address
information items. The BODY may be simply a character string, or a
very structured collection of data representing information in
different media.
The BODY may be structured to indicate a controlled presentation of
multimedia information. There is provision for the inclusion of text,
graphics, facsimile, and voice information in the body of documents.
The presentation of information units may sequential, independent, or
simultaneous.
1.5. Other Work
This protocol the benefited from the earlier work on message protocols
in the ARPA Network [2,3,4,5,6], and the ideas of others about the
design of computer message systems [7,8,9,10,11,12,13,14,15,16,17,18].
[Page 2] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
2. SPECIFICATION
The structured format of a document is built on the basic data elements
used in the Internet Message Protocol [1].
2.1. Document
The document is a property list of <name,value> pairs called fields.
A few fields are specifically required and many are optional. Some of
the field values are simple and a few are quite complicated. In
particular the body value may be highly structured.
Older message systems have considered the document to be divided into
a header and a body, and have used keywords to indicate specific
header fields (e.g., date, to, subject). Roughly speaking, this
functionality is provided in this new structured format by considering
the name part of the <name,value> pair to be a keyword. In addition,
this new structured format eliminates the separate treatment of the
body.
It is impossible to foresee the many forms documents will take so the
standard for a document header must be flexible. The approach here is
to define a set of basic fields and allow addition of whatever fields
are necessary. Features added in this fashion may not be understood
by others.
The minimum document is a property list of the following fields:
Name Value
---- -----
DATE date string (name)
SENDER a mailbox
SUBJECT subject string (text)
BODY a data structure
A typical document is a property list containing the following fields:
Name Value
---- -----
DATE date string (name)
SENDER a mailbox
FROM list of mailboxes
TO list of mailboxes
CC list of mailboxes
SUBJECT subject string (text)
BODY a data structure
Postel [Page 3]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
An elaborate document might contain the following fields:
Name Value
---- -----
DATE date string (name)
SENDER a mailbox
FROM list of mailboxes
TO list of mailboxes
CC list of mailboxes
BCC list of mailboxes
REPLY-TO list of mailboxes
SUBJECT subject string (text)
COMMENTS comment string (text)
MESSAGE-ID message identifier of this message (text)
IN-REPLY-TO message identifier of previous message (text)
REFERENCES message identifiers of other messages (text)
KEYWORDS key terms used in this message (text)
BODY a data structure
One of the key objects is the mailbox. It appears in the sender,
from, to, cc, bcc, and reply-to fields. The mailbox is a property
list of objects that combine to specify a destination recipient for a
message. Most of the <name,value> pairs that make up a mailbox are
identical to those used in the deliver command in the Internet Message
Protocol [1]. A few additional <name,value> pairs are defined for use
in a mailbox in the document context. In particular, there is a field
for the real name of a person in contrast to the "user name" which
identifies a computer account.
In addition there is a field to specify a distribution group name.
Such group names are used to indicate that a document is being sent to
a group of recipients. This essentially presents an alternate form
for a mailbox which consists of the single <name,value> pair for the
group name. There is no required relationship between a group name
mailbox and other mailboxes in the same list.
For example, all of the following situations are allowed:
. a mailbox list consisting of a single mailbox specifying a
particular user,
. a mailbox list consisting of a single mailbox with a group name,
. a mailbox list consisting of a mailbox with a group name and a
mailbox specifying a particular user, with either the user in or
not in the group,
. a mailbox list consisting of a mailbox with a group name and a
[Page 4] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
several mailboxes specifying a particular users, with some users
in the group and some not,
. a mailbox list consisting of several mailboxes specifying group
names and a several mailboxes specifying a particular users, with
some users in the groups and some not.
2.2. Message Objects
In the documents of messages, we use a set of objects such as mailbox
or date. These objects are encoded in basic data elements. Some
objects are simple things like integers or character strings, other
objects are more complex things like lists or property lists. The
following is a list of the objects used in messages. The object
descriptions are in alphabetical order.
Account
The account information. Represented by a name element.
Address
Address is intended to contain the minimum information necessary to
identify a user, and no more (compare with mailbox).
An address is a property list which contains the following
<name,value> pairs:
name description
---- -----------
NET network name
HOST host name
USER user name
or:
name description
---- -----------
MPM mpm-identifier
USER user name
Answer
A yes (true) or no (false) answer to a question. Represented by a
boolean element.
Postel [Page 5]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
BCC
A list of mailboxes. The addresses of those who receive "blind
carbon copies" of the message.
Body
A data structure. This may be as simple as a character string
(represented by a name or text element), or complex structure of
lists. It may be encrypted in part or in whole. Section 3.3
describes some possible structured bodies.
C
A character. Represented by a name element.
CC
A list of mailboxes. When copies of a message are sent to others in
addition to the addresses in the To object, those to whom the copies
are sent will have their addresses recorded here.
City
A city. Represented by a name element.
Comments
A comment string. Represented by a text element.
Count
A count of items of some sort. Represented by a integer element.
Country
A country. Represented by a name element.
[Page 6] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
Date
The date and time are represented according to the International
Standards Organization (ISO) recommendations [19,20,21]. Taken
together the ISO recommendations 2014, 3307, and 4031 result in the
following representation of the date and time:
yyyy-mm-dd-hh:mm:ss,fff+hh:mm
Where yyyy is the four-digit year, mm is the two-digit month, dd is
the two-digit day, hh is the two-digit hour in 24 hour time, mm is
the two-digit minute, ss is the two-digit second, and fff is the
decimal fraction of the second. To this basic date and time is
appended the offset from Greenwich as plus or minus hh hours and mm
minutes.
The time is local time and the offset is the difference between
local time and Coordinated Universal Time (UTC). To convert from
local time to UTC algebraically subtract the offset from the local
time.
For example, when the time in
Los Angeles is 14:25:00-08:00
the UTC is 22:25:00
or when the time in
Paris is 11:43:00+01:00
the UTC is 10:43:00
Device
A device name. Represented by a name element.
Document
A property list of fields.
Distribution Group
An distribution group is a property list which contains the
following <name,value> pair:
name description
---- -----------
GROUP document distribution group name
This construct is used so that a distribution group will be a
special case of a mailbox.
Postel [Page 7]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
Facsimile Structure
A facsimile data structure. Represented by a property list.
File
A file name. Represented by a name element.
Format
A format indicator. Represented by a name element.
From
A list of mailboxes. The From is the name of the author of a
document.
Graphics Structure
A graphics data structure. Represented by a property list.
Group
A document distribution group name. Represented by a name element.
Host
A host name. Represented by a name element.
Ident
The identifier of a person, usually their initials. Represented by
a name element.
In-Reply-To
The message identifier of previous message. Represented by a text
element.
Internet Address
This identifies a host in the ARPA internetwork environment. The
internet address is a 32 bit number, the higher order 8 bits
identify the network, and the lower order 24 bits identify the host
on that network [22]. For use in this format the internet address
is divided into eight bit fields and the value of each field is
represented in decimal digits. For example, the ARPANET address of
ISIE is 167837748 and is represented as 10,1,0,52. Further, this
[Page 8] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
representation may be extended to include an address within a host,
such as the TCP port of an MPM, for example, 10,1,0,52,0,45.
Keywords
The key terms used in this message. Represented by a text element.
Mailbox
This is the destination address of a user of the internetwork mail
system. Mailbox contains information such as network, host,
location, and local user identifier of the recipient of the message.
The mailbox may contain information in addition to the minimum
required for delivery.
As an example, when one sends a message to someone for the first
time, he may include many items to aid in identifying the correct
recipient. However, once he gets a reply to this message, the reply
will contain an Address (as opposed to Mailbox) which may be used
from then on.
A mailbox is a property list. A mailbox might contain the
following <name,value> pairs:
name description
---- -----------
MPM mpm-identifier
NET network name
HOST host name
PORT address of MPM within the host
USER user name (computer account name)
PERSON the real name of a person
GROUP document distribution group
ORG organization name
CITY city
STATE state
COUNTRY country
ZIP zip code
PHONE phone number
The minimum mail box is an Address or a Distribution Group.
Message-ID
The message identifier of this message. This is not related to the
MPM message identification, but is a UIP long term document
identifier. Represented by a text element.
Postel [Page 9]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
MPM-Identifier
The internetwork address of an MPM. This may be the ARPA Internet
Address or an X.121 Public Data Network Address [23]. The
mpm-identifier is a property list which has one <name,value> pair.
This unusual structure is used so that it will be easy to determine
the type of address used.
Net
A network name. Represented by a name element.
NLS Block
The information in an NLS node. Represented by a property list.
NLS Node
An NLS block and substructure. Represented by a property list.
NLS Substructure
A list of NLS nodes. Represented by a list.
Org
An organization name. Represented by a name element.
Paragraph
A paragraph of text. Represented by a text element.
Parcel
The basic unit of voice data. Represented by a bitstr element.
Person
The real name of a person. Represented by a name element.
Password
A password. Represented by a name element.
Phone
A phone number. Represented by a name element.
[Page 10] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
Pointer
A pointer to information stored outside this data structure. A
property list containing the information necessary to locate the
external data, the information necessary to gain access to the
external data, and the information necessary to apply the correct
interpretation to the external data. For example, this might
include:
name description
---- -----------
NET network name
HOST host name
FILE file name
USER user name (computer account name)
PASSWORD password
ACCOUNT account
FORMAT format
Port
The address of MPM within the host. Represented by a name element.
Presentation Descriptor
A property list of <name,value> pairs, where the name is an order
indicator, and the value is a presentation element. The order
indicators are SEQUENTIAL, SIMULTANEOUS, and INDEPENDENT.
Presentation Element
A property list of media structures.
Protocol
The name of the coding scheme used for a medium. Represented by a
name element.
References
The message identifiers of other messages. Represented by a list of
text elements.
Reply-To
A list of mailboxes. Sometimes it will be desired to direct the
replies of a message to some address other than the from or the
sender. In such a case the reply-to object can be used.
Postel [Page 11]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
R 450 Block
The unit of Rapicom 450 data (585 bits). Represented by a bitstr
element.
Sender
A mailbox. The sender will contain the address of the individual
who sent the message. In some cases this is NOT the same as the
author of the message. Under such a condition, the author should be
specified in the from object.
SID
An NLS statement indetifier. Represented by a integer element.
State
A state name. Represented by a name element.
Subject
The subject of the message. Represented by a text element.
Text Structure
A text data structure. Represented by a property list.
To
A list of mailboxes. To identifies the addressees of the message.
User
A user name (computer account name). Represented by a name element.
Version
A version number. Represented by a index element.
Vocoder
A vocoder name. Represented by a name element.
Voice Structure
A voice data structure. Represented by a property list.
[Page 12] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
X121 Address
This identifies a host in the Public Data Network environment. When
used as a part of identifier, it identifies the originating host of
a message. The X121 address is a sequence of up to 14 digits [23].
For use in this format the X121 address is represented in decimal
digits.
ZIP
A zip code. Represented by a name element.
2.3. Body Structures
2.3.1. Simple Elements
The body could simply be a single data element. For example a
single text element can represent a lengthy character string.
<body> := TEXT
or
text:"this is the actual text of the body"
2.3.2. Structured Text
The body could be thought of as paragraphs, where each paragraph is
represented by a text element. The paragraphs are then the elements
of a list.
<body> := LIST (<paragraph>, <paragraph>, ...)
<paragraph> := TEXT
or
list:(text:"paragraph one", text:"paragraph two", ...)
2.3.3. NLS File Example
It is possible to represent the data from NLS files in this format.
NLS is a large multipurpose system which operates on structured data
files. The files are tree structured, and there is data associated
with each node of the tree. There are several fields associated
with each node as well.
Postel [Page 13]
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
An NLS file is:
proplist( file
name:"FILENAME", name:<file> name of file
name:"CREATION-DATE", name:<date> creation date and time
name:"VERSION", index:<version> file version number
name:"SID-COUNT", integer<count> current SID count
name:"LAST-WRITER", name:<ident> last writer of file
name:"OWNER", name:<ident> owner of file
name:"LAST-WRITE-TIME", name:<date> last write date and time
name:"LEFT-NAME-DELIM-DEFAULT", name:<c> default name
name:"RIGHT-NAME-DELIM-DEFAULT", name:<c> delimiters
name:"SUBSTRUCTURE", <nls-substructure> substructure
)endlist
An NLS substructure is:
list:( substructure
<nls-node> node is defined below
.
.
.
)endlist
An NLS node is:
proplist:( node
name:"BLOCK", <nls-block> block defined below
name:"SUBSTRUCTURE", <nls-substructure> substructure
)endlist
An NLS block is:
proplist:( block
name:"LEFT-NAME-DELIM", name:<c> left name delimiter
name:"RIGHT-NAME-DELIM", name:<c> right name delimiter
name:"SID", integer:<sid> SID number
name:"CREATOR", name:<ident> statement creator
name:"CREATION-TIME", name:<date> creation date and time
name:"DATA", <data> data defined below
)endlist
[Page 14] Postel
August 1980
A Structured Format for Transmission of Multi-Media Documents
Specification
NLS data is:
proplist:( data
name:"<a data name>", <type depends on data name>
. .
. .
. .
)endlist
For text, data is:
proplist:( data
name:"TEXT", text:"text of statement" text
)endlist
2.3.4. Multimedia Structures
One can conceive of graphical information being displayed along with
a running commentary, much as seminars use slides. A slide and its
description are tied together. The coordination of such a
presentation is central to its understanding. This synchronization
should be captured within the document structure.
There are three fundamentally different types of time ordered
control which are needed within the document structure. These are:
Simultaneous
Sequential
Independent
Simultaneous data is intended for synchronous presentation. The
implication is that this data is presented in parallel.
Sequential data items will be presented one at a time, in the order
listed. The ordering is strictly left to right.
Independent data can be presented in any time order. It is not
ordered in any manner.
The data is brokethe user-PI, C, sets up TELNET connections with both
server-PI's. One of the servers, say A, is then sent a PASV
command telling him to "listen" on his data port rather than
initiate a connection when he receives a transfer service command.
When the user-PI receives an acknowledgment to the PASV command,
which includes the identity of the host and port being listened
on, the user-PI then sends A's port, a, to B in a PORT command; a
reply is returned. The user-PI may then send the corresponding
service commands to A and B. Server B initiates the connection
and the transfer proceeds. The command-reply sequence is listed
below where the messages are vertically synchronous but
horizontally asynchronous:
User-PI - Server A User-PI - Server B
------------------ ------------------
C->A : Connect C->B : Connect
C->A : PASV
A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
C->B : PORT A1,A2,A3,A4,a1,a2
B->C : 200 Okay
C->A : STOR C->B : RETR
B->A : Connect to HOST-A, PORT-a
The data connection shall be closed by the server under the
conditions described in the Section on Establishing Data
Connections. If the server wishes to close the connection after a
transfer where it is not required, he should do so immediately
after the file transfer is completed. He should not wait until
after a new transfer command is received because the user-process
will have already tested the data connection to see if it needs to
do a "listen"; (recall that the user must "listen" on a closed
data port BEFORE sending the transfer request). To prevent a race
condition here, the server sends a reply (226) after closing the
data connection (or if the connection is left open, a "file
transfer completed" reply (250) and the user-PI should wait for
one of these replies before issuing a new transfer command.
41
June 1980 IEN 149
File Transfer Protocol RFC 765
COMMANDS
The commands are TELNET character string transmitted over the
TELNET connections as described in the Section on FTP Commands.
The command functions and semantics are described in the Section
on Access Control Commands, Transfer Parameter Commands, FTP
Service Commands, and Miscellaneous Commands. The command syntax
is specified here.
The commands begin with a command code followed by an argument
field. The command codes are four or fewer alphabetic characters.
Upper and lower case alphabetic characters are to be treated
identically. Thus any of the following may represent the retrieve
command:
RETR Retr retr ReTr rETr
This also applies to any symbols representing parameter values,
such as A or a for ASCII TYPE. The command codes and the argument
fields are separated by one or more spaces.
The argument field consists of a variable length character string
ending with the character sequence <CRLF> (Carriage Return,
Linefeed) for NVT-ASCII representation; for other negotiated
languages a different end of line character might be used. It
should be noted that the server is to take NO action until the end
of line code is received.
The syntax is specified below in NVT-ASCII. All characters in the
argument field are ASCII characters including any ASCII
represented decimal integers. Square brackets denote an optional
argument field. If the option is not taken, the appropriate
default is implied.
42
IEN 149 June 1980
RFC 765 File Transfer Protocol
The following are the FTP commands:
USER <SP> <username> <CRLF>
PASS <SP> <password> <CRLF>
ACCT <SP> <account information> <CRLF>
REIN <CRLF>
QUIT <CRLF>
PORT <SP> <Host-port> <CRLF>
PASV <CRLF>
TYPE <SP> <type code> <CRLF>
STRU <SP> <structure code> <CRLF>
MODE <SP> <mode code> <CRLF>
RETR <SP> <pathname> <CRLF>
STOR <SP> <pathname> <CRLF>
APPE <SP> <pathname> <CRLF>
MLFL [<SP> <ident>] <CRLF>
MAIL [<SP> <ident>] <CRLF>
MSND [<SP> <ident>] <CRLF>
MSOM [<SP> <ident>] <CRLF>
MSAM [<SP> <ident>] <CRLF>
MRSQ [<SP> <scheme>] <CRLF>
MRCP <SP> <ident> <CRLF>
ALLO <SP> <decimal integer>
[<SP> R <SP> <decimal integer>] <CRLF>
REST <SP> <marker> <CRLF>
RNFR <SP> <pathname> <CRLF>
RNTO <SP> <pathname> <CRLF>
ABOR <CRLF>
DELE <SP> <pathname> <CRLF>
CWD <SP> <pathname> <CRLF>
LIST [<SP> <pathname>] <CRLF>
NLST [<SP> <pathname>] <CRLF>
SITE <SP> <string> <CRLF>
STAT [<SP> <pathname>] <CRLF>
HELP [<SP> <string>] <CRLF>
NOOP <CRLF>
43
June 1980 IEN 149
File Transfer Protocol RFC 765
The syntax of the above argument fields (using BNF notation where
applicable ) is:
<username> ::= <string>
<password> ::= <string>
<account information> ::= <string>
<string> ::= <char> | <char><string>
<char> ::= any of the 128 ASCII characters except <CR> and <LF>
<marker> ::= <pr string>
<pr string> ::= <pr char> | <pr char><pr string>
<pr char> ::= printable characters, any
ASCII code 33 through 126
<byte size> ::= any decimal integer 1 through 255
<Host-port> ::= <Host-number>,<Port-number>
<Host-number> ::= <number>,<number>,<number>,<number>
<Port-number> ::= <number>,<number>
<number> ::= any decimal integer 0 through 255
<ident> ::= <string>
<scheme> ::= R | T | ?
<form code> ::= N | T | C
<type code> ::= A [<SP> <form code>]
| E [<SP> <form code>]
| I
| L <SP> <byte size>
<structure code> ::= F | R | P
<mode code> ::= S | B | C
<pathname> ::= <string>
44
IEN 149 June 1980
RFC 765 File Transfer Protocol
SEQUENCING OF COMMANDS AND REPLIES
The communication between the user and server is intended to be an
alternating dialogue. As such, the user issues an FTP command and
the server responds with a prompt primary reply. The user should
wait for this initial primary success or failure response before
sending further commands.
Certain commands require a second reply for which the user should
also wait. These replies may, for example, report on the progress
or completion of file transfer or the closing of the data
connection. They are secondary replies to file transfer commands.
One important group of informational replies is the connection
greetings. Under normal circumstances, a server will send a 220
reply, "awaiting input", when the connection is completed. The
user should wait for this greeting message before sending any
commands. If the server is unable to accept input right away, he
should send a 120 "expected delay" reply immediately and a 220
reply when ready. The user will then know not to hang up if there
is a delay.
The table below lists alternative success and failure replies for
each command. These must be strictly adhered to; a server may
substitute text in the replies, but the meaning and action implied
by the code numbers and by the specific command reply sequence
cannot be altered.
Command-Reply Sequences
In this section, the command-reply sequence is presented. Each
command is listed with its possible replies; command groups are
listed together. Preliminary replies are listed first (with
their succeeding replies indented and under them), then
positive and negative completion, and finally intermediary
replies with the remaining commands from the sequence
following. This listing forms the basis for the state
diagrams, which will be presented separately.
Connection Establishment
120
220
220
421
45
June 1980 IEN 149
File Transfer Protocol RFC 765
Login
USER
230
530
500, 501, 421
331, 332
PASS
230
202
530
500, 501, 503, 421
332
ACCT
230
202
530
500, 501, 503, 421
Logout
QUIT
221
500
REIN
120
220
220
421
500, 502
Transfer parameters
PORT
200
500, 501, 421, 530
PASV
227
500, 501, 502, 421, 530
MODE, TYPE, STRU
200
500, 501, 504, 421, 530
File action commands
ALLO
200
202
500, 501, 504, 421, 530
REST
500, 501, 502, 421, 530
350
46
IEN 149 June 1980
RFC 765 File Transfer Protocol
STOR
125, 150
(110)
226, 250
425, 426, 451, 551, 552
532, 450, 452, 553
500, 501, 421, 530
RETR
125, 150
(110)
226, 250
425, 426, 451
450, 550
500, 501, 421, 530
LIST, NLST
125, 150
226, 250
425, 426, 451
450
500, 501, 502, 421, 530
APPE
125, 150
(110)
226, 250
425, 426, 451, 551, 552
532, 450, 550, 452, 553
500, 501, 502, 421, 530
MLFL
125, 150, 151, 152
226, 250
425, 426, 451, 552
532, 450, 550, 452, 553
500, 501, 502, 421, 530
RNFR
450, 550
500, 501, 502, 421, 530
350
RNTO
250
532, 553
500, 501, 502, 503, 421, 530
DELE, CWD
250
450, 550
500, 501, 502, 421, 530
47
June 1980 IEN 149
File Transfer Protocol RFC 765
ABOR
225, 226
500, 501, 502, 421
MAIL, MSND
151, 152
354
250
451, 552
354
250
451, 552
450, 550, 452, 553
500, 501, 502, 421, 530
MSOM, MSAM
119, 151, 152
354
250
451, 552
354
250
451, 552
450, 550, 452, 553
500, 501, 502, 421, 530
MRSQ
200, 215
500, 501, 502, 421, 530
MRCP
151, 152
200
200
450, 550, 452, 553
500, 501, 502, 503, 421
Informational commands
STAT
211, 212, 213
450
500, 501, 502, 421, 530
HELP
211, 214
500, 501, 502, 421
Miscellaneous commands
SITE
200
202
500, 501, 530
48
IEN 149 June 1980
RFC 765 File Transfer Protocol
NOOP
200
500 421
49
June 1980 IEN 149
File Transfer Protocol RFC 765
STATE DIAGRAMS
Here we present state diagrams for a very simple minded FTP
implementation. Only the first digit of the reply codes is used.
There is one state diagram for each group of FTP commands or command
sequences.
The command groupings were determined by constructing a model for
each command then collecting together the commands with structurally
identical models.
For each command or command sequence there are three possible
outcomes: success (S), failure (F), and error (E). In the state
diagrams below we use the symbol B for "begin", and the symbol W for
"wait for reply".
We first present the diagram that represents the largest group of FTP
commands:
1,3 +---+
----------->| E |
| +---+
|
+---+ cmd +---+ 2 +---+
| B |---------->| W |---------->| S |
+---+ +---+ +---+
|
| 4,5 +---+
----------->| F |
+---+
This diagram models the commands:
ABOR, ALLO, DELE, CWD, HELP, MODE, MRCP, MRSQ, NOOP, PASV,
QUIT, SITE, PORT, STAT, STRU, TYPE.
50
IEN 149 June 1980
RFC 765 File Transfer Protocol
The other large group of commands is represented by a very similar
diagram:
3 +---+
----------->| E |
| +---+
|
+---+ cmd +---+ 2 +---+
| B |---------->| W |---------->| S |
+---+ --->+---+ +---+
| | |
| | | 4,5 +---+
| 1 | ----------->| F |
----- +---+
This diagram models the commands:
APPE, LIST, MLFL, NLST, REIN, RETR, STOR.
Note that this second model could also be used to represent the first
group of commands, the only difference being that in the first group
the 100 series replies are unexpected and therefore treated as error,
while the second group expects (some may require) 100 series replies.
The remaining diagrams model command sequences, perhaps the simplest
of these is the rename sequence:
+---+ RNFR +---+ 1,2 +---+
| B |---------->| W |---------->| E |
+---+ +---+ -->+---+
| | |
3 | | 4,5 |
-------------- ------ |
| | | +---+
| ------------->| S |
| | 1,3 | | +---+
| 2| --------
| | | |
V | | |
+---+ RNTO +---+ 4,5 ----->+---+
| |---------->| W |---------->| F |
+---+ +---+ +---+
51
June 1980 IEN 149
File Transfer Protocol RFC 765
A very similar diagram models the Mail and Send commands:
---- 1
| |
+---+ cmd -->+---+ 2 +---+
| B |---------->| W |---------->| E |
+---+ +---+ -->+---+
| | |
3 | | 4,5 |
-------------- ------ |
| | | +---+
| ------------->| S |
| | 1,3 | | +---+
| 2| --------
| | | |
V | | |
+---+ text +---+ 4,5 ----->+---+
| |---------->| W |---------->| F |
+---+ +---+ +---+
This diagram models the commands:
MAIL, MSND, MSOM, MSAM.
Note that the "text" here is a series of lines sent from the user
to the server with no response expected until the last line is
sent, recall that the last line must consist only of a single
period.
52
IEN 149 June 1980
RFC 765 File Transfer Protocol
The next diagram is a simple model of the Restart command:
+---+ REST +---+ 1,2 +---+
| B |---------->| W |---------->| E |
+---+ +---+ -->+---+
| | |
3 | | 4,5 |
-------------- ------ |
| | | +---+
| ------------->| S |
| | 3 | | +---+
| 2| --------
| | | |
V | | |
+---+ cmd +---+ 4,5 ----->+---+
| |---------->| W |---------->| F |
+---+ -->+---+ +---+
| |
| 1 |
------
Where "cmd" is APPE, STOR, RETR, or MLFL.
We note that the above three models are similar, in fact the Mail
diagram and the Rename diagram are structurally identical. The
Restart differs from the other two only in the treatment of 100
series replies at the second stage.
53
June 1980 IEN 149
File Transfer Protocol RFC 765
The most complicated diagram is for the Login sequence:
1
+---+ USER +---+------------->+---+
| B |---------->| W | 2 ---->| E |
+---+ +---+------ | -->+---+
| | | | |
3 | | 4,5 | | |
-------------- ----- | | |
| | | | |
| | | | |
| --------- |
| 1| | | |
V | | | |
+---+ PASS +---+ 2 | ------>+---+
| |---------->| W |------------->| S |
+---+ +---+ ---------->+---+
| | | | |
3 | |4,5| | |
-------------- -------- |
| | | | |
| | | | |
| -----------
| 1,3| | | |
V | 2| | |
+---+ ACCT +---+-- | ----->+---+
| |---------->| W | 4,5 -------->| F |
+---+ +---+------------->+---+
54
IEN 149 June 1980
RFC 765 File Transfer Protocol
Finally we present a generalized diagram that could be used to model
the command and reply interchange:
------------------------------------
| |
Begin | |
| V |
| +---+ cmd +---+ 2 +---+ |
-->| |------->| |---------->| | |
| | | W | | S |-----|
-->| | -->| |----- | | |
| +---+ | +---+ 4,5 | +---+ |
| | | | | | |
| | | 1| |3 | +---+ |
| | | | | | | | |
| | ---- | ---->| F |-----
| | | | |
| | | +---+
-------------------
|
|
V
End
55
June 1980 IEN 149
File Transfer Protocol RFC 765
TYPICAL FTP SCENARIO
User at Host U wanting to transfer files to/from Host S:
In general the user will communicate to the server via a mediating
user-FTP process. The following may be a typical scenario. The
user-FTP prompts are shown in parentheses, '---->' represents
commands from Host U to Host S, and '<----' represents replies from
Host S to Host U.
LOCAL COMMANDS BY USER ACTION INVOLVED
ftp (host) multics<CR> Connect to Host S, port L,
establishing TELNET connections
<---- 220 Service ready <CRLF>
username Doe <CR> USER Doe<CRLF>---->
<---- 331 User name ok,
need password<CRLF>
password mumble <CR> PASS mumble<CRLF>---->
<---- 230 User logged in.<CRLF>
retrieve (local type) ASCII<CR>
(local pathname) test 1 <CR> User-FTP opens local file in ASCII.
(for.pathname) test.pl1<CR> RETR test.pl1<CRLF> ---->
<---- 150 File status okay;
about to open data connection
Server makes data connection
to port U
<CRLF>
<---- 226 Closing data connection,
file transfer successful<CRLF>
type Image<CR> TYPE I<CRLF> ---->
<---- 200 Command OK<CRLF>
store (local type) image<CR>
(local pathname) file dump<CR> User-FTP opens local file in Image.
(for.pathname) >udd>cn>fd<CR> STOR >udd>cn>fd<CRLF> ---->
<---- 450 Access denied<CRLF>
terminate QUIT <CRLF> ---->
Server closes all
connections.
56
IEN 149 June 1980
RFC 765 File Transfer Protocol
CONNECTION ESTABLISHMENT
The FTP control connection is established via TCP between the user
process port U and the server process port L. This protocol is
assigned the service port 21 (25 octal), that is L=21.
57
June 1980 IEN 149
File Transfer Protocol RFC 765
APPENDIX ON MAIL
The basic commands transmitting mail are the MAIL and the MLFL
commands. These commands cause the transmitted data to be entered
into the recipients mailbox.
MAIL <SP> <recipient name> <CRLF>
If accepted, returns 354 reply and considers all succeeding
lines to be the message text, terminated by a line containing
only a period, upon which a 250 completion reply is returned.
Various errors are possible.
MLFL <SP> <recipient name> <CRLF>
If accepted, acts like a STOR command, except that the data is
considered to be the message text. Various errors are
possible.
There are two possible preliminary replies that a server may use to
indicate that it is accepting mail for a user whose mailbox is not at
that server.
151 User not local; Will forward to <user>@<host>.
This reply indicates that the server knows the user's mailbox
is on another host and will take responsibility for forwarding
the mail to that host. For example, at BBN (or ISI) there are
several host which each have a list of many of the users on
several of the host. These hosts then can accept mail for any
user on their list and forward it to the correct host.
152 User Unknown; Mail will be forwarded by the operator.
This reply indicates that the host does not recognize the user
name, but that it will accept the mail and have the operator
attempt to deliver it. This is useful if the user name is
misspelled, but may be a disservice if the mail is really
undeliverable.
Three FTP commands provide for "sending" a message to a logged-in
user's terminal, as well as variants for mailing it normally whether
the user is logged in or not.
58
IEN 149 June 1980
RFC 765 File Transfer Protocol
MSND -- SeND to tnguage,"
TM-80-18, USC/Information Sciences Institute, July 1980.
[30] Graphics Standard Planning Committee, "Core System," Computer
Graphics, V. 13, N. 3, SIGGRAPH, ACM, August 1979.
Postel [Page 33]
August 1980
A Structured Format for Transmission of Multi-Media Documents
[Page 34] Postel
